United States Patent [i9] 

Coivin, Sr. 



IIIIIIIIIIIIIIIDillllllllllliillillllllDI 



US006041123A 
[11] Patent Number: 
[45] Date of Patent: 



6,041,123 
Mar. 21, 2000 



[54] CENTRALIZED SECURE 

COMMUNICATIONS SYSTEM 

[75] Inventor: Bryan Coivin, Sr., San Jose, Calif. 

[73] Assignee: Allsoft Distributing Incorporated, San 

Jose, Calif. 

[21] Appl. No.: 08/673,122 

[22] Filed: Jul. 1, 1996 

[51] Int. C17 H04L9/00 

[52] U.S. CI 380/49; 380/25 

[58] Field of Searcii 380/21, 25, 49 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,203,166 5/1980 Ehrsam et al 375/2 

4,458,109 7/1984 Mueller- Schloer 380/25 

4,484,025 11/1984 Ostermann et al 380/49 

4,578,530 3/1986 Zeidler 380/25 

4,720,859 1/1988 Aaro et al. . 

4,776,011 10/1988 Busby . 

5,003,597 3/1991 Merkle . 

5,241,599 8/1993 Bellovin et al. . 

5,263,085 11/1993 Shamir. 

5,297,206 3/1994 Orton . 

5,301,235 4/1994 Shimada . 

5,444,780 8/1995 Hartman, Jr 380/25 

5,452,358 9/1995 Normile et al. . 

5,511,123 4/1996 Adams. 

5,519,736 5/1996 Ishida . 

5,533,127 7/1996 Luther . 

5,539,827 7/1996 Liu . 

5,570,307 10/1996 Takahashi . 

5,574,673 U/1996 Lowy . 

5,600,722 2/1997 Yamaguchi et al 380/49 

5,600,724 2/1997 Masnikosa . 



5,602,845 2/1997 Wahl . 

5,602,917 2/1997 Mueller. 

5,604,807 2/1997 Yamaguchi et al 380/21 

5,608,k)2 3/1997 Alvarez . 

5,613,005 3/1997 Murakami et al. . 

5,619,576 4/1997 Shaw . 

5,623,545 4/1997 Childs et al. . 

5,627,894 5/1997 Albert et al. . 

5,657,390 8/1997 Elgamal et al 380/49 

5,661,803 8/1997 Cordery et al 380/49 

5,825,881 10/1998 Coivin, Sr. 380/25 

OTHER PUBLICAnONS 

Marvin A. Sirbu, "Internet Billing Service Design and 
Prototype Implementation"; IMA Intellectual Property 
Project Proceedings, (vol. 1, issue 1, pp. 67-79; Jan. 1994). 
Brian Santo, "Bill-paying Put On-line"; Electronic Engi- 
neering Times (n840, p. 82; Mar. 20, 1995). 
"The NetBill Electronic Commerce Project"; Carnegie Mel- 
lon University; May 15, 1995. 

Bruce Schneier, Applied Cryptography^ 2nd Edition, 1996, 
p. 419. 

Primary Examiner — Salvatore Cangialosi 

Attorney, Agent, or Firm — McCutchen, Doyle, Brown & 

Enersen, LLP 

[57] ABSTRACT 

A system of secure communications between multiple par- 
lies. This system uses an index/secure key combination for 
each party. The index key never changes its value. A secured 
central router with access to a master database uses index 
keys to look up corresponding secure keys in the master 
database. The central router uses the secure keys to decrypt 
messages sent by parlies and reencrypt the messages for the 
recipients and, thus, acts as a conduit for secure communi- 
cations between parties. 

14 Claims, 2 Drawing Sheets 



Sender 
Index Key 16 



Local 
Secure 
Key 



Encfyplor 



T 



Sctxlcr 
Client 

— \ 



II 



Recipient 
Index Key 
17 



Recipient^ 
Client 



Unciyptor 




Local 


used as a 




Secure 


'Dccrvplor 




/Key 



Insecure Wide Area Network such as the Internet 



Master Key Router 



Dcciyplor 




7 

Temporary 




Decr^or 
acting as 


1 


Pile 




^ 


an 

Encryptor 




05/28/2004, EAST version: 1.4.1 



1 




05/28/2004, EAST Version: 1.^.1 



U.S. Patent 



Mar. 21, 2000 



Sheet 2 of 2 



6,041,123 




o 



hanfs 
sfront 


private 


Merc 
Ston 


m 
O 





S cn 


PnvatQ 
Kay 


Merc 

Man; 


n 



05/28/2004, EAST Version: 1.4.1 



6,041,123 

1 2 

CENTRALIZED SECURE client has a secure key and an encryptor/decryptor for 

COMMUNICATIONS SYSTEM encrypting and decrypting messages using the secure key. In 

FIEL D OF THE INVENTION preferred embodiments of the present invention, communi- 
cations between chents pass through a master key router. 

The present invention relates to communication over a ^ ^^^^^ ^ ^^^^^^ ^ ^^^^^^ ^^^^^ 

public network and, more particularly, to secure transmis- ^.^nications among cUents by translating an encrypted mes- 

sion of information over a public network, ^^^^ ^^^^ ^ ^^^^^ ^j.^^^ ^^^^ ^^^-p.^^^ ^^^^^^ 

BACKGROUND OF THE INVENTION using their respective secure keys. 

Public computer networks, such as the Internet, are Preferred embodiments of the present invention further 

increasingly being used to conduct confidential communi- 10 include a master key server having a database in which 

cations. In order to keep such communications secure, one duplicates of clients* secure keys are stored. The master key 

must prevent unauthorized access to confidential data, main- server has the capability to look up a client's secure key by 

tain the integrity of the communications and data, and referring to an index key associated with the client, 

authenticate the origin of data that has been received. ^ ^y^^j ^^^^^^ invention is, therefore, to provide 

A variety of encryption systems have been developed to is improved communications system, 

address these needs. Different encryption systems offer * *u * r *i. . • • . i**;, 

,.rc .J c * T *■ i ** Another obiect of the present invention is to simplify 

different degrees of secunty. In conventional encryption , • u • *u j * t. 

systems, the recipient of the message generally has some secured comniunications by removing the need to exchange 

knowledge related to an original and secure key used to session keys before the transmission of data, 

encrypt the message. This constitutes a major hmitation on Yet another object of the present invention is to provide a 

the degree of security current systems can provide. communications system which achieves increased security 

For example, most conventional encryption systems, such for information communicated over the system by ensuring 

as PGP (pretty good privacy), use a mathematical relation- there is no discoverable relationship between the key used 

ship that ties both private and public keys together, thereby by a recipient client to decrypt a message and the key used 

creating a temporary "working key" that is identical on each 25 the sending client to encrypt the message, 

end of the transmission. This mathematical relationship is A further object of the present invention is to provide a 

based upon the product of two very large prime numbers of communications system which achieves heightened security 

the form: (2''o)-l. Once this product is known, the secure for information communicated over the system by allowing 

key can then be determined and the entire system is jeop- the secure key to be extremely large, 

ardized. 30 Still another object of the present invention is to provide 

Another problem with conventional systems is the fact a communications system with increased security for infor- 

that the sender and recipient must typically exchange a mation communicated over the system by restricting access 

"session key" before the sender may engage in secure to the system to clients who engage in communications for 

communications with the recipient. For example, the sender a particular purpose. For example, the present invention can 

may need first to give out its public key to the recipient and 35 protect the integrity of commercial transactions conducted 

wait to receive a "session key" from the target recipient over the communications system by allowing only com- 

before the sender can finally send out its message. The merce to take place and forbidding transmission to non- 

"session key" returned to the sender may be a function of the commercial entities. 

sender's public key, intermixed with the recipient's private A further object of the present invention is to provide a 

key. The substantial delay resulting from the need to create 40 communications system which does not require a "static" 

and communicate "session keys" between the sender and secure key. By changing the secure keys of sending clients 

recipient before any communications can occur reduces the after each transmission, the present invention makes future 

efiSciency of the communications system. messages unrelated to prior messages, thereby making the 

Moreover, if the session key is a function of the sender's secure key a "moving target" and therefore more difEcult to 

public key and the recipient's private key, those keys must 45 decipher. 

remain static in order to continue using the prior-negotiated An additional object of the present invention is to provide 

session keys. If either key is changed, the sender and a communications system which achieves heightened secu- 

recipient must renegotiate the exchange of session keys, rity for information communicated over the system by 

thereby further reducing the efficiency of the system. assigning each client an encryption algorithm that is, for all 

Finally, traditional encryption systems are inefiBcient in 50 practical purposes, unique, 

sending the same message to multiple parties, A single Yet another object of the present invention is to provide a 

sender must encrypt the same message differently for each communications system which allows a client to send a 

targeted recipient and transmit each encrypted message single message to multiple recipients while spending a 

separately. minimal amount of time on the system. 

The need for increased security is becoming more acute as 55 These and other objects of the present invention will 

communications and data transmitted across unsecured become apparent to those skilled in the art from the follow- 

media such as the Internet become more seasitive and ing detailed description of the invention and preferred 

valuable. Moreover, increasing volume and sophistication of embodiments, the accompanying drawings, and the 

transmissions has created a need for a more efficient encryp- appended claims. 

tion system. 60 BRIEF DESCRIPTION OF THE DRAWINGS 

Accordingly, there is a need for an encryption system 

which reduces disadvantages associated with conventional FIG- 1 is a block diagram of the logical structure of a 

encryption systems. communications system according to the present invention 

having a plurality of clients and incorporating a master key 

SUMMARY OF THE INVENTION ^5 server and master key router as a conduit for decrypting and 

Broadly stated, the present invention encompasses a com- encrypting communications between clients connected to 

munications system used by a plurality of clients. Each the system. 
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FIG. 2 is a block diagram of a merchandising system 
embodiment of the present invention. 

DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENT(S) 5 

The present invention encompasses a wide variety of 
communications systems. Such systems preferably have a 
plurality of clients connected to a wide area network. Under 
such systems, a Master Key Router is also connected to the 
network. ITie Master Key Router receives encrypted com- 
munications from a sending client, decrypts the information, 
reencrypts the information in a specific manner such that a 
particular receiving client can decrypt it, and sends the 
reencrypied information to the receiving client. In preferred 
embodiments of the present invention, the Master Key 
Router is one or more computers acting as a router for cUent 
communications and a centralized means for encrypting and 
decrypting client communications. 

Under some preferred embodiments, the Master Key 
Router obtains secure keys and information about the 
encryption/decryption methods of the sending and receiving 
cUents necessary to perform its functions from a Master Key 
Server which contains a database with secure keys and 
encryption algorithm numbers for each client indexed by 
that client's public index key. 

The logical structure of a preferred embodiment of a 
communications systems according to the present invention 
wherein a client may send a secure transmission to one or 
more other clients is shown in FIG. 1. The preferred system 
comprises at least one Sender Client 11 and at least one 
Recipient Client 2, a Wide Area Network 3, a Master Key 
Router 4, and a Master Key Server 8. The Sender Client 11 
and Recipient Client 2 each have a Local Secure Key 12, 14 
(respectively). The Sender Client 11 has a Sender Index Key 
16 and the Recipient Client 2 has a Recipient Index Key 17. 
The Sender Client 11 has an encryption/decryption means, 
Encryptor 1 (hereinafter referred to as "Sender's Encryptor/ 
Decryptor 1"), which the Sender Client 11 uses as an 
encryptor. The Recipient CUent 2 also has an encryption/ 
decryption means, Encryptor used as a Decryptor 13 
(hereinafter referred to as "Recipient's Encryptor/Decryptor 
13"), which the Recipient Client 2 uses as a decryptor. 

The Master Key Server 8 includes a Database 9 which 
contains secure keys for all existing clients in the system 45 
indexed by each client's corresponding index key. The 
Master Key Router 4 includes a Decryptor 5 and a Decryptor 
Acting as an Encryptor ("DAE") 7. The DAE 7 is an 
inverted encryptor that uses a decryption algorithm for 
encryption purposes. While the preferred embodiments of jq 
the present invention contemplate that a large number of 
clients will be connected to the system and that each 
individual client could be a Sender Client 11 or Recipient 
Client 2 at any given time, for the sake of clarity, only one 
Sender Client 11 and one Recipient CHent 2 are depicted in 55 
FIG. 1. 

A Sender Client 11 provides information which is to be 
encrypted and ultimately communicated to a Recipient Cli- 
ent 2. After decrypting the message, the Recipient Client 2 
should have access to a communication which is exactly the go 
same as the original communication transmitted by the 
Sender Client IL 

In a preferred embodiment of the present invention, each 
client has an index key and a secure key. Once a client is 
assigned an index key, the key never changes. A chent's 65 
secure key, however, changes after that client sends a 
transmission. Each client also has a client program which 



generally provides a user interface and communications 
protocols which allow the client to communicate on the 
Wide Area Network 3. It will be apparent to those skilled in 
the art based on the present disclosure that a wide variety of 
traditional methods may be used to create a client program 
with adequate user interfaces and communications proto- 
cols. 

The client program further includes a client encryption 
algorithm, made up of an algorithm engine patched with the 
client's algorithm number, which can be used to encrypt 
messages being sent by the client (Sender's Encryptor/ 
Decryptor 1) or decrypt messages received by the client 
(Recipient's Encryptor/Decryptor 13). The method for gen- 
erating client algorithms is disclosed below. Based on the 
present disclosure, those skilled in the art will understand 
how to implement the disclosed method for generating client 
algorithms within the client program. 

The secure communications process under the preferred 
embodiments of the present invention begins with the 
Sender Client 11 who provides information to be commu- 
nicated to a Recipient Client 2. The Sender Client 11 also 
adds a small address header to the original message refer- 
encing the Recipient Index Key 17 which serves to instruct 
the Master Key Router 4 where ultimately to send the 
message. The Sender's Encryptor/Decryptor 1 (the sender 
client's encryption algorithm) located within the sender's 
client program takes the message information and address 
header from the Sender Client 11 and scrambles the data 
using the Local Secure Key 12. The message information 
and address header are encrypted serially and then trans- 
mitted through a Wide Area Network 3 along with the 
Sender Index Key 16 to the Master Key Router 4. 

Encryption and decryption are fully reversible processes. 
Information that is encrypted using a particular algorithm 
can be decrypted using the inverse algorithm. Conversely, 
information that is encrypted using the inverse of a particu- 
lar algorithm can be decrypted using the original algorithm. 
Preferably, each client is given only one encryption algo- 
rithm as a method of encoding data because the reverse 
process is difiBcult to derive. Under the preferred embodi- 
ment each client has only one algorithm (and not the inverse 
of that algorithm) within its client program to encrypt and 
decrypt its data messages. In FIG. 1, the sender client's 
algorithm is labeled the Sender's Encryptor/Decryptor 1 and 
the recipient client's algorithm is labeled the Recipient's 
Encryptor/Decryptor 13. Although different labels are used, 
for illustrative purposes, to identify the client algorithms in 
FIG. 1, it should be appreciated that all client algorithms are 
able to function as an encryptor or decryptor depending on 
whether the client is sending or receiving messages at any 
given time. 

Under some preferred embodiments of the present 
invention, the Master Key Router 4 and Master Key Server 
8 serve as a conduit for secure communications between the 
Sender Client 11 and the Recipient Client 2 by decrypting 
the message from the Sender Client 11 using the inverse 
algorithm of the Sender's Encryptor/Decryptor 1 and 
re -encrypting the message for transmission to the Recipient 
Client 2 using the inverse algorithm of the Recipient's 
Encryptor/Decryptor 13. 

In preferred embodiments of the present invention, the 
Internet serves as the Wide Area Network 3. The Internet 
uses File Transport Protocol or "FTP", to send and receive 
data files. As part of this protocol, a data packet is given a 
FILE NAME which is used to refer to the data file as it is 
being read or written. The FILE NAME of the data files that 
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get sent to the Master Key Router 4 is an 8-bit file name that 
matches exactly the Sender Index Key 16. This 8-bit char- 
acter key uses a subset of ASCII characters that represent 
legal file names on a multitude of operating systems such as 
UNIX, and IBM-PC DOS. Because the Sender Index Key 16 5 
is known by virtue of the FILE NAME, the Master Key 
Server 8 is able to look up the client* s corresponding Secure 
Key 12 in the Database 9. The Recipient Index Key 17 and 
IP address (or URL) are contained in a header to the sender's 
message and are used by the Master Key Router 4 and 10 
Master Key Server 8 to determine where to send the message 
and how to encrypt the message for transmission to the 
Recipient Client 2. 

An advantage of some preferred embodiments of the 
present invention is the ability to give each client what is ^5 
effectively a different encryption algorithm to use locally. 
Thus, even if a secure key were discovered, however, 
unlikely, it would only have meaning if it is also associated 
with the particular encryption algorithm used by the client. 
Each chent's particular algorithm is defined by a corre- 20 
sponding algorithm number. The algorithm number defines 
the initial conditions of the internal random number genera- 
tor and other subtle changes to process flow in an algorithm 
engine. Each particular algorithm number is applied 
("patched") to the algorithm engine, thereby modifying the 25 
program data used by the algorithm engine. The result is a 
different encryption algorithm for each chent. The method of 
creating a multiplicity of algorithms while giving the Master 
Key Server 8 and Master Key Router 4 access to all 
algorithms is disclosed further below. 

In preferred embodiments of the present invention, the 
Database 9 has each client's secure key and algorithm 
number. As with secure keys, the Master Key Server 8 is 
able to retrieve the algorithm number by a client's index key. 
Once retrieved from the Database 9, both the sender chent's ^ 
Secure Key 12 and corresponding algorithm number get 
passed to the Decryptor 5 contained in the Master Key 
Router 4. 

The Decryptor 5 uses the sender client*s Secure Key 12 
and the sender's particular algorithm number obtained from 
the Database 9 to decrypt the information transmitted by the 
Sender Qient 111 fully. The Decryptor 5 then delivers a copy 
of the decrypted information to a Temporary File 6 (memory 
resident). At that time, the header containing the Recipient 
Index Key 17 and Internet FILE NAME is stripped from the 
message and transferred to the DAE 7 to be used to transmit 
the final message ultimately to the Recipient Client 2. 

The DAE 7 requests the recipient client's algorithm 
number and Secure Key 14, from the Database 9 in the 50 
Master Key Server 8. The Database 9 looks up those items 
using the Recipient Index Key 17. The DAE 7 determines 
the inverse algorithm of the Recipient's Encryptor/ 
Decryptor 13 from the recipient's algorithm number and 
uses that inverse (which, in the preferred embodiment, is a 55 
decryption algorithm used to perform encryption) to reen- 
crypt the information from the Sender Client 11. The Master 
Key Router 4 then sends the reencrypted information to the 
Recipient Client 2 through the Wide Area Network 3 by 
referencing the Recipient Index Key 17 and other informa- go 
tion contained in the header. 

The Recipient Client 2 receives the reencrypted informa- 
tion from the Master Key Router 4 and uses the Recipient's 
Encryptor/Decryptor 13 to decrypt the message. This is 
possible because the Master Key Router 4 earlier used the 65 
inverse algorithm of the Recipient's Encryptor/Decryptor 13 
to reencrypt the sender's message. Thus, the Master Key 
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Router 4 acts in conjunction with the Master Key Server 8 
to perform a translation from the sender client's Secure Key 
12 and corresponding algorithm number to the recipient's 
Secure Key 14 and corresponding algorithm number. 

In preferred embodiments, the Master Key Server 8 also 
contains a Secure Key Update 15 which modifies the sender 
client's Secure Key 12 after a communication is sent by that 
client. After a communication, the Secure Key Update 15 
automatically generates a modifier string of numbers to send 
to the Sender Client 11 , That modifier string is determined 
from the client's Secure Key 12 and a string of random 
numbers. The Secure Key Update 15 obtains information 
regarding the sender's location from the Decryptor 5 which 
has just completed decrypting the sender client's message. 
Before the modifier string is sent it is encrypted for access 
by the Sender Client 11 using the DAE 7, the current Secure 
Key 12, and the sender client's algorithm number. The 
encrypted data packet is then sent to the Sender Client 11. 

The data packet is received and decrypted using the 
sender's encryption algorithm. Sender's Encryptor/ 
Decryptor 1. The data packet then instructs the chent's Local 
Secure Key 12 to modify itself to a new form based on the 
modifier string. This same modifier string which was created 
in the Secure Key Update 15 is also used to update the 
sender client's secure key in Database 9 so that the next time 
a message is either sent or received by the Sender Client 11, 
the modified Secure Key 12 will be used. In order to prevent 
the secure keys from getting out of sync, handshaking 
messages are sent between the Sender Client 11 and the 
Master Key Server 8 to ensure that both sides will be able 
to communicate in the future. 

In preferred embodiments, a client's secure key is modi- 
fied only when the client sends a message. Any client, 
however, may also manually request modification of its 
secure key. That request is sent directly to the Secure Key 
Update 15. Also, a client's algorithm number and index key 
is never modified. Once established, the algorithm number 
and index key for a particular client is left unchanged. 

In preferred embodiments, the Master Key Server 8 
further includes a New Chent Initializer 10 which can 
integrate new users into the communications system. Under 
preferred embodiments, the potential new client uses a "web 
browser" program that accesses an "HTML" form which the 
new client fills out. As part of this form, the new client types 
in a password and other information such as its operating 
system type and the like. The form is sent to the New Client 
Initializer 10 which creates a new index key based on a 
sequential numbering system. Also created is an algorithm 
number (a string of eight bytes in the preferred embodiment) 
for the new client. In preferred embodiments, the algorithm 
number for each client is generated randomly. 

The New Client Initiahzer 10 also creates a master client 
program. That program contains an algorithm engine which 
is "patched" with the new client's algorithm number which 
results in an encryption algorithm for the new client. This 
algorithm can now perform as a Sender's Encryptor/ 
Decryptor 1 or Recipient's Encryptor/Decryptor 13 depend- 
ing on whether the new client is sending or receiving 
messages. The new client's algorithm number is stored in 
the Database 9 and indexed using the new client's index key. 

An initial secure key is created for the new client by 
initializing a pseudo random number generator with the new 
client's password entered on the HTML, form, algorithm 
number, and index key. This initial generator routine is 
contained within the master client program and the New 
Client Initializer 10. Once generated, the initial secure key 
is stored in the Database 9, indexed by the new client's index 
key. 
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Conventional methods may be used to create an initial 
secure key for a new client. In preferred embodiments, the 
method allows for initializing a pseudo random number 
generator with the new client password, algorithm number 
and index key. An example of such a method is illustrated 5 
below in C++ programming language: 



void UpdateKcy(char*Key,char*SEED) 

{ 10 
Ran.[nit(SEED); // initialize random number generator 

// with a seed comprising 
// a string called SEED 

for(int i-0;i<arraysize;i++) 

Key[i] "Ran.getnextbyteQ; 
> 15 
Random number class:: 
void ran::Imt(char*messup) 

{ 

int i; 

for(i=0;messup[i];i++)statc[i&7] =messup[i]; // 8 state variables 

} 20 
byte ran::getnextbyteO 

{ 

statefO] =state[l]; // modify states to 

state[l] =statef2}t-state[8]; // a new value. Any arbitrary 
// lossless function then 
// randomizes state variable 
// in a constant way 

return state[0]; 
} 
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A program in the Master Key Server 8 generates a local 
configuration file that contains future private information 
about the new client as well as the new client's password 
from the HTML form. This configuration file is preferably 
encrypted using a simple prior art encryption system. One 
such method includes using a random number generator 
seeded with the new client's index key and algorithm 
number Each byte of the random number generated is 
XORed with the contents of the configuration file. Decryp- 
tion is performed by using the same process (the inverse 
algorithm is the same as the original algorithm in this case). 

The client program and configuration file is compressed 
and transmitted using a self -extracting "ZIREXE" program 
and sent to the new client over the Internet 3. The new client 
must remember and use its password that was entered on the 
HTML page in order to install and use the client program. 
Once the password is verified, the client program installs 
itself and generates an enabled local secure key for the new 
client. The random number generator contained in the down- 
loaded client program used to create the enabled secure key 
is identical to the generator used by the New Client Initial- 
izer 10 to create the new client's initial secure key. Because 
the downloaded secure key generator is seeded with the 
same combination of the new client's password, index key, 
and algorithm number, the enabled secure key is identical to 
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the new client's initial secure key created by the New Client 
Initializer 10 and already stored in Database 9. 

In order to ensure the new client's secure key is suffi- 
ciently randomized at the outset and to protect against the 
possibility that the initial secure key was compromised 
during the new client initialization process, each new client 
requests modification of its secure key from the Secure Key 
Update 15 before it can participate in any secured commu- 
nications within the system. 

Those skilled in the art will appreciate that the present 
invention effectuates communications between a sender 
client and muhiple recipient clients. Under the preferred 
embodiment, the Master Key Router 4 and Master Key 
Server 8 are linked to the Wide Area Network 3 through a 
high bandwidth connection. Clients, however, are typically 
linked to the system using a low bandwidth connection, such 
as a modem over a phone line. Under preferred embodi- 
ments of the present invention, the sender need not copy its 
message to each and every recipient the sender wishes to 
communicate with. Nor does the sender need to concern 
itself with the encryption/decryption needs of the individual 
recipients. Instead, the Master Key Router 4 in conjunction 
with the Master Key Server 8 may copy a single message to 
a multitude of recipients and handle all attendant encryption/ 
decryption functions through its higher bandwidth connec- 
tion. As a result, the sender spends less of its own time and 
resources using the system. 
CYCLIC REDUNDANCY CHECK (CRC) 

In order to validate a given message and secm^e it against 
erroneous transmissions, preferred embodiments of the 
present invention employ a system called Cyclic Redun- 
dancy Check ("CRC"). Under this system, the Sender Client 
11, before transmitting its message to the Master Key Router 
4, first passes all of its message data through a CRC 
algorithm which generates a CRC number based on that 
message data. When the Sender Client 11 transmits its 
message to the Master Key Router 4, the CRC number 
accompanies the message as a small block of data appended 
to the end of the transmission. After the Master Key Router 
4 decrypts the message from the sender, it mns the message 
data through the same CRC algorithm. The Master Key 
Router 4 then compares the resulting CRC number with the 
CRC nmnber transmitted from the sender. If they match, the 
Master Key Router 4 is assured the sender's message has not 
been altered. 

There are a multitude of methods for creating a CRC 
system. The best method to create such a system uses a 
random number generator fed by the actual message data 
stream. As an added measure of security, the CRC number 
may be calculated before the document is encrypted by the 
Sender Client 11. Below is a C++ class object that discloses 
an example of how to create a random number-based CRC: 



class CRC 
{ 

public: 

CRCO; 

void INITO; // reset CRC 

void PUT(char); // advance CRC using next character 

void GEr(char *); // copy to a string of 8 chars 

private: // numbers are not NULL terminated 
unsigned char K[8];// state variables used to create random number 
unsigned char C(8]; 
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-continued 



CRC::CRCO 
{ 

INITO; 

} 

void CRC::INrrO 
{ 

for (int i=0;i<8;i++) 
( 

K[i]=i''7+19; 
C[i]=i+23; 

} 

} 

void CRC::GET(char *P) 
{ 

for(int i=0;i<8;i++) P[i]=C(i]; 

{ 

void CRC::PUT(char P) 
{ 



// initialize starting state 



// initialize random number seed 



} 



C[0] x=(P + (-P«3)) 
C[l] "-QO] ' KIO]; 
q2] -C[l] + K[l]; 
C[3]--q2] K[2]; 
C[4] = C[3] + K[3] + P; 
C[5] +- Ct4] * K[4]; 
C[6] -C(5]-K(5]; 
C[7]+-C(6] K[6]; 
K(0] — (P « 1) + K[7]; 
K[]] '= P» 2; 
K{2] += ~P; 
Kt3] += P; 

K(4] += C[0] ' qi]; 
K(5]"=q4] P; 
K(6] += C[0] « 1; 
K[7] '= qO] » 1; 



K[7]; 



// transfer 8 byte final result 



// randomize and insert input character ' 
// each state equation is modified by an 
// arbitrary XOR, ADD, or SUB function. 
// one or more equations must include "P" 



35 



HEADER & FOOTER 

Under preferred embodiments of the present invention a 
header is used in order to communicate certain information 
to the Master Key Server 8 including sender and recipient 
index keys. The footer simply adds the CRC to the end of the 
package. Under th e preferred embodiment, the header, 
message(s) to be sent, and footer may be defined as follows: 



-continued 



MAIN HEADER 
Note: each Item has a leading and trailing dollar sign. 
Each line ia terminated with a control-E character 



ITEM 



FORMAT EXAMPLE 



ITEM 



MAIN HEADER 
Note: each Item has a leading and trailing dollar sign. 
Each line is terminated with a control-E character 

FORMAJ' EXAMPLE 



45 



50 



Number of Source Documents 

Number of Destinations 

URL of Destination #1 
Pointer to Source Document 
INDEX KEY of Destination #1 
URL of Destination #2 
Pointer to Source Document 
INDEX KEY of Destination #2 



URL of Destination #n 
Pointer to Source Document 



INDEX KEY of Destination #n 
Size of Document #1 in hexadecimal bytes $5A83$ 
Size of Document #2 $351$ 



$nnn$ where nnn is a 

hexadecimal number 

$mmm$ where mmm is a 

hexadecimal number 

joe_blow@foo.com 

$3$ use third input document 

A78KCC31 

jain__blow@foo.com 

$1$ use first input document 

A7SOCY3A 



http :/Avww. f 00 .com 
$nnn$ nth input document to 
use starting from 0 
6HU57BT 



Size of Document #n $AFE$ 
Concatenated Source Documents 

Note; each document is stand alone and does not require separation 
markings as was used in the main header. The main header already 
defined 

the size of each source document. 
Document #1 
Document #2 

Document #n 
Footer 

Note: no termination is necessary 

CRC 8 Bytes 



55 
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ENCRYPTION and DECRYPTION 

There are many methods available for encrypting and 
decrypting data. Generally, the best methods to use in the 
present invention are those in which the methods for encryp- 
tion by the sender differ from the methods of decryption by 
the recipient. This makes the job of reverse engineering 
much more difiScult because of the fact that the decryption 
algorithm is not "shipped" to the recipient with the sender's 
transmission. Under preferred embodiments of the present 
invention, only the Master Key Router 4 has the ability to 
decrypt the sender's original encrypted message. 
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Reverse engineering entails taking executable code and 
creating source code from it. Executable code contains no 
comments or labels and does not look like the language in 
which the original source was created. The executable code 
appears as an incomprehensible series of machine code 5 
instructions. The code used in the preferred embodiment has 
many branches which further complicates matters. It would 
take a great deal of time just to create C++ code from the 
machine code. 

Even after deriving source code from the executable code, lO 
the inverse algorithm must still be derived because it is not 
available and not part of the executable code. Even a 
programmer experienced in cryptography will have trouble 
deriving the inverse algorithm because the algorithm code 
used in preferred embodiments of the present invention is 15 
extremely different from the typical programs of its class. 

In any event, the enormous size of the secure key in 
preferred embodiments of the present invention will serve as 
an extreme deterrent to those who wish to access commu- 
nications within the communications system. 20 

Preferred embodiments of the present invention include a 
system for creating a family of encryption algorithms such 
that each client uses a different encryption algorithm. Each 
client's encryption algorithm is defined by a particular 
algorithm number. The algorithm number consists of a block 25 
of data with a size of 1 or more bytes. The client's encryp- 
tion algorithm is generated by patching the algorithm num- 
ber to an algorithm engine contained within the client 
program. The patch affects the initial conditions of the 
algorithm engine's random number generator, the pointers to 30 
state variables, and other controls. Because each client has 
a different algorithm number, each client ends up with a 
different encryption algorithm. 

During the new client initiation process, a random algo- 
rithm number is assigned to the new client. A master copy 35 
of the client program containing an algorithm engine is 
modified by poking in the number of bytes corresponding to 
the new client's algorithm number in a fixed location of 
memory within the algorithm engine. The resulting encryp- 
tion algorithm along with the rest of the client program is 40 
ultimately downloaded to the new client to enable that cUent 
to engage in secure communications in this system. 

Because encryption and decryption using the encryption 
algorithms in preferred embodiments are fully reversible 
processes and because clients' encryption algorithms are 45 
defined solely by their algorithm numbers, the Master Key 
Router 4 needs only to obtain a particular cHent's algorithm 
number from the Master Key Server 8 to decrypt messages 
from or encrypt messages to that client. 

Those skilled in the art will appreciate that there are a 50 
plethora of methods that may be used to modify the encryp- 
tion and decryption pair. In preferred embodiments of the 
present invention, the methods must ensure that the pair are 
exact reversals of each other. Most encryption systems use 
a random number generator initialized by a seed derived 55 
from the secure key and then perform an XOR function with 
the data stream to be encrypted. 

Several aspects of preferred embodiments of the present 
invention frustrate the use of traditional encryption analysis 
programs to access communications within the system. The 60 
client algorithm must first be reverse engineered in order to 
break into the system. 

Moreover, sparse use of the secure key in preferred 
embodiments provides a significant security benefit by 
allowing the system to use an extremely large key without 65 
slowing down the performance of the encryption system. 
Because larger secure keys allow for a greater number of 
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possible combinations for the key, the larger the secure key 
used, the more difficult it is to decipher. Therefore, use of an 
extremely large secure key helps prevent unauthorized 
access to communications within the system. 

Preferred embodiments of the present invention use a key 
size of 256 bytes which is equivalent to 2CM-8 bits. Prior art 
systems typically use secure keys which range from 64 bits 
to 256 bits in length. The prior art generally does not 
disclose systems using secure keys larger than 256 bits. The 
enormous size of the secure key used in the preferred 
embodiments of the present invention will likely frustrate 
any brute force attempt to crack the code. 

Also used in preferred embodiments of the present inven- 
tion is a sparsely used array of state variables. The state 
variables form a huge random sequence generator which is 
used further to encrypt the data. Each pass of the encryption 
system, producing one character of encrypted data, modifies 
one out of the 256 state variables which is a function of one 
out of 256 secure key characters. Several of the states in this 
pool of state variables which get pointed to by one or more 
of the algorithm data elements, are used to form a localized 
random number stream that further encrypts the data stream. 

Embodiments of the present invention may also utilize a 
"method pointer", initialized by a client's specific algorithm 
number, to cause each data element in the stream of data to 
be encrypted using a different method of scrambling the 
data. Preferred embodiments use twelve different methods to 
scramble data (although more could be used). The sequence 
of methods used is determined by the client's algorithm 
number. Because the method pointer is initialized using a 
specific algorithm number, starting with different initial 
parameters will result in an entirely different combination of 
encryption methods. In order to decipher the message, 
potential analysis systems must determine the EXACT com- 
bination of methods used to encrypt the message. 

Added to the arsenal of encryption methods used in 
preferred embodiments of the present invention are revers- 
ible maps. A reversible map has the following property: 
x=MAP[MAP[x]]. Also used are several reversible func- 
tions. These have the following property: 



z = F(x, y); // scramble 

X » F(z, y); or x - G(z, y); // unsaamble Use G if F is not its own 
inverse function. 



Where: y is a modifier, x=input data, z=encrypted data, and 
F(x, y) a reversible function. 

G(x, y) is an alternate function for the reversal process 
making F & G related. 

The combination of all these techniques yields an 
encryption/decryption system virtually impossible to crack. 
As long as the secure key remains secret, preferred embodi- 
ments of the invention approaches absolute security. Modi- 
fying the secure key after each use in some preferred 
embodiments may further secure the system by creating a 
moving target. 

On the following pages is an example of a C++ program 
function that implements the above-discussed methods: 

As discussed above, in preferred embodiments of the 
present invention, algorithm numbers are randomly gener- 
ated for each client and stored in the Database 9 indexed by 
the client's corresponding index key. In an alternative 
embodiment, algorithm numbers for each client are gener- 
ated by means of a pseudo-random number generator using 
the client's specific index key as a seed. When the Master 
Key Server 8 requires a client's algorithm number, it derives 
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the algorithm number from that client's index key using the time a customer clicks on an item in a store, the information 
same pseudo-random number generator. Thus, in this aher- is stored in a logical "shopping cart." When the customer 
native embodiment, client algorithm numbers do not need to finally clicks on "go to cashier " a file containing all selected 
be stored in the Database 9. items gets transmitted to the customer in a single file. This 
Similarly, while the preferred embodiments of the present 5 file is lightly encrypted and sent to the customer for further 
invention contemplate that each client in the system may processing. Along with this file is a password that is used by 
send and receive messages at any time, it will be apparent to the customer to encrypt merchant and money processor data 
those skilled on the art based on the present disclosure that P^^^^^^^ merchant and the money pro- 
other embodiments of the invention can include one or more cessor systems, respectively. After these data packets are 
^ . , , ui* * A * created, they are combined in a single file, encrypted, and 
clients who lack the capabUity to send messages to receive lO ^^^^ ^J^^ ^ ^^^^^ ^^^^^^ ^ ^^^^^ 

ZZ%\Ki^j<^t^r °' '^^^'^^ messages. ^^^^ ^^^^^^ ^^-^ ^1^^ ^pj.^^ ^^^^ ^^^^ ^^^^^^^^ ^^^^^ 

MERCHANDISING ^j^^ merchant data packet and the money processor data 

In a merchandising system according to the present p^^^^et, and ships each packet to its final destination. Before 

invention, transactions are conducted over a large public f^i^^ ^re shipped out, they are again encrypted. Master key 

network, such as the Internet. Each transaction involves a 15 ^^^^j^ loi has a copy of each customer's secured key and 

merchant, a customer and a financial institution (or money therefore, possesses the capability to decrypt the data, 

processor) that use computer systems connected to the Because there are two levels of encryption, the Master Key 

network. Server 101 is blind to the actual data packets being sent out. 

Each merchant, customer and financial institution that Merchant system 103 has several forms of communica- 

may participate in transactions has its own secure key. A 20 tions. First, it has a local database 117, which stores each 

copy of each key also exists in a central, secure database customer's order, all inventory items, and pricing informa- 

system that is also connected to the network. Each customer tion. This database is tightly integrated into the virtual 

also uses a free "internet consumer kit" containing the store's software system. The merchant has a direct commu- 

software for conducting transactions. Internet consumer kits nications path 108 to the Money Processor Server System 

preferably are widely available. For example, the kits may 25 109 and a direct path 106 to the Customer. Communication 

be made available at each participating merchant. Each on these paths is performed outside of the knowledge of 

merchant uses an integrated communications software pack- Master Key Server 101 so that private passwords may be 

age that includes a database, a customer interface, a bank used to create a two- level encryption system, 

interface, and a virtual HTML store generator. A wide Merchant Manager 112, communicates to the storefront, 

variety of software for implementing the above features, and 30 via the Master Key Server 101 over the Internet via path- 

those features described herein, will be apparent to those 113. Merchant Manager 112 typically runs on a personal 

skilled in the art based on the present disclosure. computer and is password protected. This allows the Store 

The customer selects products to purchase by accessing a Manager to add inventory items and change pricing infor- 

merchant's Web site and clicking on one or more "links" that mation. Each system that communicates to Master Key 

put the products in a "virtual shopping cart." The customer 35 Server 101 must have a secured key which matches a 

then clicks a "checkout link" that causes an itemized priced secured key contained in the Master Key Server's database, 

list to be downloaded to the customer's computer. Once Money Processor 104, communicates directly with a 

downloaded, this information is merged with information financial institution (e.g. a bank) 105, via path- 111. Current 

locally stored on the customer's computer. ITie local cus- methods for conducting such communication include 

tomer's computer system then adds sales tax information 40 modems running on a private line direct to the bank. In other 

and sends this information along with a shipping address embodiments, the bank is also the money processor server 

back to the merchant. Credit card information from the client 104, thereby eliminating communications path-Ill. Money 

is sent directly to the bank; the merchant never receives the processor system 104 receives a one-way communications 

customer's credit card information. The bank informs the packet via path-108 from the merchant store system giving 

merchant that the transaction is complete. 45 it a password that will be later used to unlock a data packet 

The structure of a merchandising system according to the originating from the customer. Communications from the 

present embodiment is described in more detail below in money processor system back to the Merchant is routed 

connection with FIG. 2. For the sake of clarity, FIG. 2 shows through the Master Key Server 101 via path- 110. 

only a single merchant computer system and a single cus- Each logical client of the master key server system (i.e., 

tomer system. It is understood that the present embodiment 50 each customer, merchant, and money processor computer 

permits any number of merchant and customer systems, system) that owns a secured key has that key updated 

each of which operates as described below. The merchant, following each transmission or reception of data by that 

customer and money processor computer systems shown in client. This creates a moving target; in the unlikely event that 

FIG. 2 independently run interrelated software programs and a secured key is discovered, it is valid only for a single 

function as a group to permit merchandising according to the 55 transaction and from a single customer. There is no way that 

present embodiment. this knowledge may be applied to other transactions; thus, 

A master key server system 101 acts as a secure commu- security is greatly improved. The most viable attack on the 

nications router. Master key server 101 communicates with security of this system would be to break into the building 

various computer systems over the Internet or other public where the master key server is located and load all the 

network system. The communication paths between master 60 secured keys. This is where the double blind method is 

key server and various other computer systems are shown as useful; information passing through the Master Key Server 

path-107, path- 109, and path-110, is not usable because it is sent in encrypted form which 

Customer computer system 102 initiates communications. cannot be decrypted by the Master Key Server. 
Customer system 102 obtains information from the mer- The merchandising system uses a series of inter- 
chant computer system 103 over communication path-106. 65 connected communications to perform a transaction. The set 
Information generally is sent in the form of HTML pages of basic communications used by this merchandising system 
that are dynamically created by the merchant system. Each is described below. 
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1. Merchant to Customer 

A customer finds a merchant Web site, clicks on the items 
that he desires to purchase, and presses the "BUY IP' hnk 
on his web browser software. Clicking on "BUY IT* causes 
a packet of information to be downloaded (FIG. 2 — path 5 
106), The name of the file being downloaded has a 3-letter 
sufBx, such as ".ASD", which causes what is commonly 
known as a "Helper Application" to run and receive this file 
being downloaded from the Merchant via the Internet. The 
downloaded file is lightly scrambled and contains a custom 
CRC checking system that validates the contents of this file. 
Light scrambling is defined as the process where all the 
information necessary to unscramble the message including 
the key is sent together in one file. The decryption algorithm 
is contained within the customer's receiving program is 
identical to all customer programs. The information being 
sent is not sensitive information; it only details what the 
customer has purchased. The purpose of the light encryption 
is to reduce the possibility of a bogus file accidentally 
causing the customer program to respond. Even if someone 
were to figure out how to create a fake merchant, the file 
would eventually get thrown out because the master key 
server will not communicate with a merchant that is not in 
the master key database. 

The downloaded and lightly encrypted file created by the 
merchant contains the following information: 

(1) The merchant's account number and purchase order 
number. This number will eventually get passed along 
to the money processor system 104 by the customer, 
and allows the money processor system to know which 
merchant account to credit. 

(2) The merchant's order number. This number keeps 
track of which order is which. This number will even- 
tually get sent back to the merchant for tracking pur- 
poses. This number is also used by the processor 
system 104. 

(3) An encryption key. This key is used to keep the master 
key server 101 honest. Data packets are encrypted two 
times using two different algorithms. The master key 
server 101 removes one level so that it can re-encrypt 
the packet and send it to another location. It does not 
know how to decrypt the second level however. It 
merely sends the data packet "as is" on to the next 
location. This double -blind method keeps all informa- 
tion that flows through the master key server unrecog- 45 
nizable as an added level of security. The Merchant 
sends the encryption key not only to the client, but also 
the money processor 104. This enables the Merchant to 
perform the second level of decryption of the data 
packet originating from the client. 50 

(4) The list of Items that the customer selected. This 
information will eventually turn into a receipt that the 
customer may print out or save to his hard disk. 

(5) A series of equations defining post-processing activi- 
ties. The merchant is blind to information such as state 55 
and local taxes. In order to avoid any need for the 
customer to enter tax-related information into a form, 
post processing via a local calculator is performed on 
the customer*s computer. As information eventually 
flows back to the merchant, the merchant may then 60 
account for the sales tax collected by receiving the state 
and county information from the customer. This makes 
shopping much less of a hassle by minimizing the 
amount of information that a customer has to enter into 
the Merchant's Store "HTML Page". 65 

(6) A list of information items that the merchant requires 
to ship the product to the customer. This list includes 



shipping address, and name. Other options may also be 
requested such as EMAIL address, and telephone num- 
ber. The customer has the option to block information 
to the merchant. 

2. Customer to Master Key Server 

After this information is received in the customer's 
computer, a special application program that resides on the 
customer's computer is launched using as input the contents 
of the file sent by the merchant. This application performs 
the following functions: 

(1) Decrypts the message being sent by the merchant; 

(2) Calculates local and sales taxes if any; 

(3) Prompts the user to choose a credit card or ATM card 
to pay for the items that he selected at the merchant's 
store (the credit card numbers were previously stored); 

(4) Creates two data packets: one to be sent back to the 
merchant, and the other to be sent to the credit card 
processing center or bank; 

(5) Encrypts these two data packets using a "medium 
security" encryption method with the password that 
was sent to the customer via the data packet sent by the 
merchant; 

(6) Combines these two data packets and creates a header 
detailing where they are to be sent; 

(7) Encrypts the entire information packet with a "mas- 
sive encryption system" that only the master key server 
can decrypt; and, 

(8) sends this file to the master key server. 

3. Master Key Server to Merchant and Money Processor 
Systems 

The master key server receives this packet sent by the 
customer. The file sent to the master key server 101 uses the 
8 character index key name which looks up the customer's 
secured key in the master key database. The master key 
server: 

(1) Decrypts the packet sent by the customer using that 
customer's index key to lookup a secured key which is 
stored in the master key database. The index key is 
passed to the master key database by virtue of the 
physical name of the file which was transmitted. In 
other words the file name and index key name are 
identical. 

(2) Reads the header information that tells the master key 
server where to send the information. This header also 
defines the size of each data packet, the index key 
which will be used to encrypt the data packet, and the 
Internet address of where to send this packet. Also 
included is the name of the file that will be downloaded. 
The name sent to the processor is a combination of the 
order number, and the merchant account number 
(which said merchant account number happens to be 
the merchant's index key). The name of the file sent 
back to the merchant is the order number. 

(3) Separates each data packet and re-encrypts each data 
packet using the target secured key associated with the 
secured key of the recipient. The master key server uses 
the "decryption" algorithm to "encrypt" the data. This 
helps to further secure the data because the algorithm to 
encrypt is different from the algorithm to decrypt. 
Deriving the decryption algorithm from the encryption 
algorithm is a difficult and painfully slow process at 
best. This process includes reverse engineering several 
client programs. 

In some embodiments, clients' algorithms are determined 
from the clients' corresponding index keys. Thus, in such 
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embodiments, the master key server has the capability to 
derive a client*s algorithm from that client's index key. 

In other embodiments, the master key server stores each 
client's corresponding algorithm number in its database 
along with the client's secure key. In such embodiments, the 5 
master key server is able to access a client's algorithm 
number in the database by referring to the chent's index key. 
Thus, in such embodiments, the client algorithm is unrelated 
to the client index key. 

(4) Sends each data packet to the recipient. One data 
packet goes to the merchant, the other to the bank or 
credit card processor. 

4. Money Processor To/From Merchant 

Money processor system 104 receives a data packet, but 
does not know how to decrypt it. It must receive information 
concerning decryption directly from the merchant. This 
decryption entails a password string that was sent to the 
customer. The merchant originally created this password 
string and tells the customer and the processor what it is 
without the master key server ever having access to this 
information. This double blind method keeps the master key 
server honest. 

The Merchant receives its data packet which contains an 
order number, tax information, the total price and the 
customer's shipping address. At no time is the credit card 
number exposed to the merchant or any other sensitive 
information that it has no business seeing. This keeps the 
credit card information very safe. The merchant will even- 
tually receive a message from the credit card processor 
which vahdates the order. This information is used to change 
the "WEB PAGE" informing the customer that all transac- 
tions have completed. 

After each use of the master key server, the secured key 
changes through a process of handshaking. The master key 
server passes a random string of characters to each client that 
sends a packet of data. (Note; receiving a data packet will 
not update the secret key. A merchant receiving a flood of 
data is a parallel process. Merchants and money processors 
change their keys on a scheduled basis. The merchant and 
processor may also have a block of keys so that it can update 
them on a rotating basis.) This random string of characters 
modify the old secured key creating a new secured key. Both 
the client and the master key server update their respective 
secured keys in the same way after handshaking has com- 
pleted. Handshaking is performed as follows: 

(1) Master Key Server sends a data packet containing a 
string of random numbers. This data packet is 
encrypted using the old secured key. 

(2) Client creates a new secured key while saving the old 
one based on the random data it received after decryp- 50 
tion. 

(3) Client sends a message back to the Master Key Server 
using the "New Secured Key", The message reads: OK 
I got it! This message is preceded by a string of 256 
pseudo random numbers generated by using the previ- 55 
ous random data it received as a seed. The seed was 
also previously initialized by the index key and algo- 
rithm number. 

Also part of the header is the "command" which tells the 
master key server that this is a key update handshake 50 
message and not a packet transmission. 

(4) Master Key server receives this packet, checks the 256 
numbers for validity, and returns a message back to the 
client further validating the new key. This message uses 
the new secured key. 65 

(5) The Chent then throws away the old key and uses the 
new key. 
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Each client is defined as either a customer, a merchant, or 
a bank. In the unlikely event that the secured keys get out of 
sync, a client may request a new key. This is driven by the 
client who sends a special message to the master key server. 
This message uses yet another encryption system based on 
the index key and the algorithm number. The client com- 
mands the master key server to discard the old index key, 
and to issue a new one. This encryption is necessary to 
prevent someone from throwing away a key that does not 
belong to him. This action will also cause the customer to 
loose all of the information contained within his local 
database including all credit card information. This process 
helps to remove orphaned index keys from cluttering the 
database. Also, if the system is not used in a year's time from 
the last use, the index key is deleted from the database. 

The client program is password protected. If the client 
forgets his password, he will have to reenter all of the 
information contained within his database. It is not neces- 
sary to get a new index key. The password protection is put 
in place to prevent the situation where the family computer 
is stolen. This also prevents kids from using the system. 

The credit card server is totally automated requiring no 
human intervention. In the event that something goes wrong, 
the customer may call the bank or credit card processing 
center. This information is contained within the final web 
page displayed by the merchant. That page will either tell the 
user that the transfer of money was successful or provide a 
reason for its rejection. Some common problems may be as 
follows: credit card expiration date has expired; credit line 
has been exceeded; credit card reported lost or stolen; given 
name on credit card does not match actual name. 

There are also two logical merchants that parallel each 
other. One is the actual store, the other is the store manager. 
The store manager communicates with the actual store by 
using the master key server. The store manager has a special 
software package that has the abihty to command the store 
to upload or download its current inventory database, 
change pricing information, or add new items to the data- 
base. The store manager may also change the look and feel 
of the store by uploading new graphics, and logos. This 
software package is written in such a way as to remove the 
complexity of creating HTML forms, programming SQL 
database engines, and other complex activities making the 
store manager able to do what he does best. This store 
manager software package is also password protected. This 
prevents dishonest employees from changing price informa- 
tion without the knowledge of the store manager. In the 
event that the store manager forgets his password, a system 
is put in place to extract this password. This is done using the 
following procedure: 

(1) Store manager calls a mall manager, the mall manager 
being an entity with means to authenticate the identity 
of store managers. 

(2) Mall manager verifies that the store manager is who he 
says he is by comparing his appUcation with verbal 
questions. 

(3) The mall manager then provides a temporary pass- 
word that takes the store manager to a later screen 
which allows the merchant to enter in a new password. 
This temporary password is based on the combination 
of the index key for the store, the index key of the store 
manager, and a pseudo random number based on a seed 
created by the secured key; the mall manager does not 
see the secured key, but only the resulting random 
number. Built into this temporary password is a self- 
checking CRC. This temporary password only works 
one time and only on this one machine. 
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(4) A screen comes up asking the merchant manager to 
enter in a new password. 

(5) The merchant manager must then retype the password 
5 times for penance as well as pay the mall manager a 
hefty fine! 

In the event that the secured keys for the merchant 
manager gets out of sync, the manager must download an 
"emergency repair kit". This kit is password protected, 
where the password must be received verbally over the 
phone by the mall manager. This repair kit also fixes the 
combined problem of a forgotten password and a out of sync 
secured key. This uses the same above process except for the 
fact that the locally stored secured key is used instead of the 
copy that resides in the master key server. This process of 
resynchronizing is different than that of a customer, because 
of security issues. Also, there is no locally stored informa- 
tion other than the secured key and password on the mer- 
chant manager's computer. 

A merchandising system according to the present inven- 
tion is particularly useful in connection with the popular 
Hyper-Text Markup Language ("HTML") used on the World 
Wide Web, a graphical communications system that runs 
over the Internet. In HTML, links point to other locations 
and files on the Internet. A link uses an addressing scheme 
similar to how mail is delivered by the post office. Domain 
Name Services have been deployed allowing the user to type 
in plain text instead of what are known as IP addresses. 
Currently an IP address contains 4 bytes each separated by 
the colon character. Below are several examples of IP 
addresses: 



313:46:5:199 51:191:77:192 
373:112:255:66 133:7:51:101 



This provides roughly 4 billion addresses that may be 
used. Each of these addresses could potentially have what is 
known as a domain name. These domain names are regis- 
tered and distributed on multiple computers and routers. A 
router is a device that sends information from one server to 
another. Several examples of Internet addresses interpreted 
by Domain Name Service are as follows: 



http://www.allsoft.disti.coni/index.html 
http ://www.m icrosofl. com 
ftp://ftp.lLnksys.com 
gopher://liberty.uc.wlu.cdu/pubUQ/ 



The first series of characters up to and including the "//" 
defines a communications protocol. This tells the "Internet 
Web Browsers" how to interpret a data package that will 
eventually get transmitted. ^Ilie next section contains the 
domain name. Domain names end in suffixes such as; net, 
com, edu, org, and pri. A domain name may also contain a 
one or more prefixes such as "www*'. Each prefix is delim- 
ited by a period. The computer that owns that domain name 
resolves these prefixes to a physical IP address or a directory. 
Following the domain name is a directory path name the 
most common being "/index.html" which indicates the offi- 
cial starting home page for that domain. 
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Another function of the Internet that predates web pages 
is EMAIL. An EMAIL address uses one or more prefixes 
such as someone's name, and appends "@" plus the domain 
name. Several examples are shown below: 
^ gary@foo.com 

bill@whitehouse.gov 

mark.ee 1 @aol .com 

Many "Internet Web Page Browsers" have what are 
10 known as "helper apps". A helper application is invoked 
when a file name containing a file extension consistent with 
that application. These helper application suffixes are pro- 
grammable. Some examples follow: 



15 



Extension name: 


Program: 


".zip" 


winzip.cxe 


".wav" 


mplayer.exe 


".ps" 


gscript.exe 


".doc" 


msword.exe 



This merchandising system uses the above concept of a 
"helper app" in order to launch the customer program that 

25 receives the information firom the merchant which also sends 
this information back to the merchant and bank mixed with 
the customer's personal information. 

The program that the customer runs is only capable of 
performing encryption intended for commerce only. The 
customer may only communicate with the bank and the 
merchant via the master key server (FIG. 2-101), The 
algorithm used cannot be easily modified to be used as a 
standalone encryption system. The system is further 

35 restricted by not allowing customers to talk to other cus- 
tomers. The information that gets sent by the customer is 
nothing more than credit card numbers, shipping address, 
name and purchase total. This kind of information does not 
pose a national risk, nor can facihtate drug trafficking to take 

40 place. This removes the barriers and restrictions concerning 
the export of this encryption technology. 

It is relatively easy to establish a "virtual store". The store 
manager can remotely change prices, add inventory items, 
and even change the look of his store. This is done using a 
"store manager" program. This program is tightly integrated 
with the store front. Security is maintained because only the 
computer that has the store manager's secured key can 
change the store. The software is also password protected 
preventing dishonest employees from changing price infor- 

50 mation. Also included in this software package is an inter- 
face between the "Internet's virtual store" database, and the 
main database used by the merchant. For smaller shop 
keepers, it is also possible for the store manager to run his 
entire business from the virtual store's database keeping 

55 shipping logs, inventory, and all other aspects of running a 
business. 

While the present invention has been described in con- 
nection with specific embodiments, the present invention is 
not limited to such embodiments and encompasses modifi- 
60 cations and equivalent arrangements within the scope of the 
appended claims. 
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// A\ 

// CRYPT W 

// W 

// A single key is used for both encode and decode. There are multiple W 
5 // methods used to scramble the data. The methods change as a function W 
// of which byte is being scrambled. The secure key is 2048 bits long. W 
// This system also uses a unique data-spinning system to defeat any W 
// future attempt to analyze the data stream. Secure keys are rotated \\ 
// each and every time the master key server is accessed. W 

#defme STD_OFF 210 
^include "globals.h" 
^include <stdio.h> 
1 5 typedef unsigned char byte; 



// \\ 

// Class Definition W 

// \\ 

20 



class CRYPT 
{ 

public: 

15 CRYPT(char ♦); // use a string of stuff as a key 

CRYPT(FILE *); // load secure key direct from file 

// constructor for master CRYPT program only: 

30 #ifdef_MasterCRYPT 

CRYPT(FILE ♦.char *); // pass 8 chars to pick an algorithm 
CRYPT(char *,char *); // use string as a key 
#endif 

35 CRYPT(CRYPT &other); // copy just in case you need to back up! ! ! ! 
void InitEncoderO; 
void InitDecoderO; 
byte Encode(byte); 

40 // only the master can decode a message! 

#ifdef__MasterCRYPT 
byte Decode(byte); 

void POKE_ALG(char *); // insert algorithm constants 
45 void PEEK_ALG(char *); //get 
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#endif 

void UpdateKey(FILE *, char *); // save new key, mess up with string! 
private: 
void InitQ; 

void INCO; // bumps StatePointer 

byte ROLL(byte,bytc); // barrel rotate 
byte SWAP{byte.byte); // bit swapper 
byte SUM(byte,byte); // add 
byte SCRAMBLE(bytc); 
byte UNSCRAMBLE(byte); 
char PrivateKey[257]; 

byte STATE[256]; // changes with each new input 



byte PKEY[256]; // stays constant 

int StatePointer; 
int KeyPointer; 
int Method; 
byte Spin; 

byte DataSpinZ; // data dependent spin cycle 

byte DataSpinY; 

int CopyPtr; // use copyright notice for encryption 

char *AlgorithmPointer; 

}; 

// 

// CLASS Implementation \\ 
II, .^^ 

// this routine causes the secure key file to modify itself and may be used 



// before or after a transmission of data. 

void CRYPT::UpdateKey(FILE ♦Wr, char *K) 

// assume file already opened! 

int i, j; 
byte c; 

for(i==0o=0;i<256;i++j++) 
{ 

if(JKU])j=0; 

c = K|jrPKEY[irSTATE[i]; 
fputc(c, Wr); 

} 

fclose(Wr); 



27 
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CRYPT::CRYPT(char ♦A) // A must be less than 256! ! 
( 

int i, j; 

// hide the Algorithm number inside the copyright notice data array!! 
AlgorithmPointer=G_CopyRight; AlgorithmPointer*-^STD_OFF; 
for(i=0;A[i];i++); 

for G=Ou<iU++) PrivateKey[j]=Atj]; 

PrivateKey[j]=0; 

InilEncoderQ; 

} 

CRYPT::CRYPT(FILE *F) 
{ 

intj; 

AlgorithmPointer=G_CopyRight; AlgorithmPointerH=STD_OFF; 
for G=0ij<256u++) 
{ 

PrivateKey[j]=fgetc(F); // add file check later.... 
if (IPrivateKeyU]) PrivateKey[j]++; // forbid 0! 

} 

fclose(F); 

PrivateKey[256]=0; 
InitEncoder(); 

} 

#ifdef_MasterCRYPT 

// use index key string to generate algorithm number 

CRYPT: :CRYPT(char *A,char ♦ST) 
{ 

int i, j; 

AlgorithmPointer=G_CopyRight; AlgorithmPointerf=STD_OFF; 
for(j=0;j<8j++) 
{ 

AlgorithmPointer[j] = ST[j]; // modify global data block to match client 

} 

i=9+(AlgorithmPointer[0]&7); // mess up to create the key 
forG=Ou<i;j++) 
{ 

AlgQrithmPointer[0]''= ((byte)AlgorithmPointer[3] » I) 

+ (AlgorithmPointer[7] « 1 ); 
AlgorithmPointer[l ]+= (byte)AlgorithmPointer[0] 
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+ (byte)AlgorithmPointer[2]; 
AlgorithinPointer[2]'^ AlgorithmPointer[0] « 1 ; 
AlgorithmPointer[3]+= (byte)AlgorithmPointer[l] » 2; 
AlgorithmPointer[4]+=G_MAP0[AlgorithmPointer[2]&0xff|; 
AlgorithmPointer[5]'^ AlgorilhmPointer[3] + AlgorithmPointer[4]; 
AlgorithinPointer[6]+= G_MAP1 [AlgorithmPointer[5]&0xfr|; 
AlgorithmPointer[7]^- AlgorithmPointer[6]+AlgorithmPointer[l ]; 

} 

for (i-0;A[i];i++); 

for (j=Oij<i;j++) PrivateKey[j]=A|j]; 

PnvateKey[j]=0; 

InitEncoderO; 

) 

CRYPT: :CRYPT(TILE *F, char *ST) // use file as a key 
{ 

int i, j; 

// point to modify block 

AlgorithmPointer=G_CopyRight; AlgorithmPointer+=STD_OFF; 
forG^0;i<8ij++) 
{ 

AlgorithmPointer[j] = ST|j]; // modify by assignment 

} 

i=9+(AlgorithmPointer[0]&7); // mess up to create the key 

forO=0;j<iu-f+) 

{ 

AlgorithmPointer[0]^ ((byte)AlgorithmPointer[3] » 1) 

+ (AlgorithmPointer[7] « 1 ); 
AlgorithmPointer[l ]+= (byte)AlgorithmPointer[0] 

+ (byte)AlgorithmPointer[2]; 
AlgorithmPoimer[2]''= AlgorithmPointer[0] « 1 ; 
AlgorithniPointer[3]-r= (byte)AlgorithmPointer[l] » 2; 
AlgorithniPointer[4]+= G_MAP0[AlgorithmPointer[2]&0xffl; 
AlgorithmPointer[5]'^= AlgorithmPointer[3] + AlgorithmPointer[4]; 
AlgonthmPoimer[6]H-= G_MAP1 [AlgorithmPointer[5]&0xff|; 
AlgorithmPointer[7]''= AlgorithmPointer[6]+AlgorithmPointer[l ]; 

} 

for(j=0;j<256y^-f) 
{ 

PrivateKey[j]=fgetc(F); // add file check later.... 
if (!PrivateKey[j]) PrivateKey[j]++; // forbid 0! 

} 

fclose(F); 

PrivateKey[256]=0; 
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InitEncoderO; 

} 



void CRYPT::POKE_ALG(char +8) // insert algorithm constants 
{ 

for (int i=0;i<8;i++) AlgorithmPointer[i] = B[i]; 

} 

void CRYPT::PEEK_ALG(char ♦B) // Copy algorithm number constant 
{ 

for (int i=0;i<8;i++) B[i]=A!gorithmPointer[i]; 

} 

#endif 

void CRYPT: :InitO 
{ 

StatePointer=(byte)AlgGrithmPointer[0]; 
KeyPointer=(byte)AlgorithmPointer[ 1 ]; 
Method=AlgorithniPointer[2] & 7; 
Spin-0; 

DataSpin2=(byte)AlgorithmPointer[3]; 
DataSpinY=(byte)AlgorithmPointer[4]; 
CopyPtr=STD_OFF; 
int i; 

for (i=0;i<256;]-H-) 
{ 

PKEY[i] = i ^ Ox5A ^ G_CopyRight[i] ; 
STATE[i]= i ^ OxBC ^ G_CopyRight[i+l]; 

} 

for (i=0;i<256;i++) 
{ 

PKEY [STATE[(i'^AlgorithniPointer[6])&& OxfT]] ^= 

(STATE[R0LL(PKEY[i^xabl)],3); 
STATE[STATE[(i'^AIgorithmPointer[5]) && Oxff]] ^= 

(PKEY [R0LL(PKEY[i^xea],2)]); 

} 

} 

void CRYPT::InitEncoder() 
{ 

int i=OJ=0,k=0»zz; 

Z2=l 01 7+(byte)AlgorithmPointer[7]; 

byte Munge=^0; 
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initO; 

for (i=^0;i<zz;i++) 
{ 

if (PrivateKey[j]=0) j=0; 
k &=OxFF; 

PFCEY[k] ^= (Munge PrivateKeyQ]); 

k4-+;j-H-; 

} 



void CRYPT: :INC() // modift^ next use of pointers into the two arrays 

{ 

StatePointer+=23; 
StatePointcr&=Oxff; 
KeyPointer+=3l; 
KeyPointer&-Oxff; 

} 



byte CRYPT: :Encode(byte A) 
{ 

byteB; 

B=A''DataSpinZ'^DataSpinY; // introduce data into random sequence generator 

DataSpinY+=DataSpinZ; 

DataSpinZ^=A; 

A=B; 

switch (Method) // use a different method of encryption for each byte of data 

{ 

caseO: // Simple XOR ... 

B - A ^ STATE[StatePointer] ^ PKEY[lCeyPointer]; 
INCO; 

STATE[KeyPointer]^=PKEY[StatePointer]; 

Method++; 

break; 

case I; // ROLL with XOR ... 

B = ROLL(A,(PKEY[KeyPointer]'^7)+l) ^ STATE[PKEY[StatePointer]]; 
INCO; 

STATE[StatePointer]'^= AlgorithmPointer[0]; 

Method++; 

break; 

case 2: // BIT SWAP with XOR ... 

B = SWAP(A,STATE[StatePointer]) ^ PKEY[STATE[KeyPointer]]; 
INCO; 

STATE[StatePointer]^- ROLL(PKEY[KeyPointer],3); 
Method++; 
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break; 

case 3:// ADD with XOR ... 

B = SUM(A,STATE[StatePointer]) ^ PICEY[K:eyPointer]; 

INCO; 

STATE[KeyPoinler]^ROLL(STATE[StatePointer].PKEY[KeyPointer]); 
Method-H-; 
break; 
case 4: //SCRAMBLE 
B = SCRAMBLE(A); 
INCO; 

STATE[KeyPomter^StatePointer]^= 

SWAP(PICEY[ICeyPomtcr],PKEY[StatePointer^0x5a]); 
Method++; 
break; 
case5://LUT #0 

B - G MAP1[G_MAP0[A] STATE[StatePointer] ^ PKEY [Key Pointer]]; 

INCO; 

STATE[KeyPomter]^PKEY[G_MAPO[StatePointer]]; 
Method++; 
break; 
case6://LUT#l 

B - G_MAP0[G_MAP1[A] ^ STATE[StatePointer] ^ PKEY[Key Pointer]]; 
!NC(); 

STATE[KeyPointer]^=PKEY[G_MAPl[KeyPointer]]; 

Method^O; 

break; 

} 

B^=Spin; 

Spin PKEY[KeyPointer]'^STATE[Spin+l]; 
STATE[(byte)AlgorithmPointer[l ]]^ S WAP(Spin,STATE[Spin]); 
STATE[(byte)AlgorithmPointer[2]]'^ 

SWAP(Sp!n'^STATE[(byte)AIgorithmPointer[l]], STATE [StatePointer]); 

B''=G_CopyRight[CopyPtrf-+]; // use copyright notice to mess up stuff!! 
CopyPtr&=Oxff; 

return B; 



byte CRYPT: :SUM(byte A, byte N) // reversible function 
( 

return (byte)((N+A)&Oxff); 

} 
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// only the master key system may do this: 

/^ifdef„MasterCRYPT 

byte CRYPT: :Decode(byte A) 
{ 

byteB; 
A'^^Spin; 

A^=G_CopyRight[CopyPtr++]; 
CopyPtr&=Oxff; 
switch (Method) 
{ 

case 0: // Simple XOR ... sort of 

B = A ^ STATE[StatePomter] ^ PKEY[KeyPointer]; 
INC(); 

STATE[KeyPointer]^PKEYrStatePointer]; 

Method++; 

break; 

case 1 : // ROLL with XOR ... 

B = ROLL(A^STATE(PKEY[StatePointer]],PKEY[ICeyPointer]); 
INCQ; 

STATE[StatePoiiiter]^= AlgorithmPointer[0]; 

Method++; 

break; 

case 2: // BIT SWAP with XOR ... 

B = SWAP(A,STATE[StatePointer] PICEY[STATE[KeyPointer]]); 
INC(); 

STATE[StatePointer]^- ROLL(PKEY[KcyPointer],3); 

Method++; 

break; 

case 3: //SUB with XOR... 

B = SUM(A PKEY[KeyPointer],-STATE[StatePointcr]) ; 
INC(); 

STATE[KeyPointer]^ ROLL(STATE[StatePointer],PKEY[KeyPointer]); 
Method-H-; 
break; 
case 4: //Unscramble 

B - UNSCRAMBLE(A); 
INCQ; 

STATEpCeyPointer^StatePointer]^- 

SWAP(PKEY[KeyPointcr],PKEY[StatePointer^0x5a]); 
Method++; 
break; 
case 5:// LUT #0 

B = G_MAP0(G_MAP1[A] ^ STATE[StatePointer] ^ PKEY [Key Pointer]]; 
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INCO; 

STATE[KeyPointer]^=PKEY[G_MAPO[StatePointer]]; 
Method++; 
break; 
case 6://LUT#l 

B = G_MAP1[G_MAP0[A] ^ STATE[StatePointer] ^ PKEYfKeyPointer]]; 
INCO; 

STATE[KeyPomier]^=PKEY[G_MAP 1 [Key Pointer]]; 

Method=0; 

break; 

} 

// each use of the AlgorithmPointer causes the algorithm to behave differently 
Spin ^= PKEY[KeyPointer]'^STATE[Spin+l]; 
STATE[(byte)AlgorithmPointer[l]]^- SWAP(Spin,STATE[Spin]); 
STATE[(byte)AJgorithmPointer[2]]^ 
SWAP(Spin^STATE[(byte)AlgorithmPointer[l]],STATE[StatePoimer]); 

A=B''DataSpinZ'^DataSpinY; // undo data entered into random data stream. 
DataSpinY+=DataSpinZ; 

DataSpinZ'^=A; // reverse data dependent encryption! 
return A; 

1 

#endif 

void CRYPT:;ImtDecoder() { InitEncoderQ; ) 



CRYPT::CRYPT(CRYPT &other) 
{ 

int i; 

for (i=0;i<256;i++) 
{ 

STATE[i]=other.STATE[i]; 

PKEY[i]-other.STATE[i]; 

PrivaleICey[i]==other.PrivateKey[i]; 

} 

StatePointer=other.StatePointer; 
KeyPointer = other.KeyPointer; 
Method = other.Method; 
Spin = other.Spin; 
DataSpinZ = other.DataSpinZ; 
DataSpinY = other. DataSpinY; 
CopyPtr = other. CopyPtr; 
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AlgorithmPointer - other. AlgorithmPointer; 

} 

// This routine rotates the bits in 'A' left by 'N' unless 0 
byte CRYPT: :ROLL(byte A, byte N) // reversible function 
{ 

byte R; 
N&=7; 

if (N==0) // no rotation? just XOR the data with a constant. 
{ 

R = A ^ AlgorithmPointer[4]; 

} 

else 
{ 

int i=A; 
i«=N; 

i-(i&Oxff)l(i » 8); 
R=i; 

} 

return R; 

) 

byte CRYPT::SCRAMBLE(byte A) // does a mix of stuff 
{ byte R; 

R=SWAP(STATE[StatePointer],A); 
R=SUM(STATE[KeyPointer],R); 
R^= PKEY[StatePointer]; 
return R; 

} 

byte CRYPT: :UNSCRAMBLE(byte A) // undoes a mix of stuff 
{ byte R; 

R=A ^ PKEY[StatePointer]; 
R-SUM(-STATE[KeyPointer],R); 
R=SWAP(STATE[StatePointer],R); 
return R; 

} 



byte CRYPT: :SWAP(byte A. byte N) // reversible function 
{ 

// AABBCCDD swapped niblets 
byte R,TUT2; 
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N&=0x70; 
switch (N) 

{ 

case 0x00: // A <-> B 
5 Tl =(A&OxC0)»2; 

T2 = (A&0x30)«2; 

R =(A&OxOf)|Tl \ n: 

break; 
case OxlO://B<->C 
10 Tl =(A&0x30)»2; 

T2 - (A & 0x0C)«2; 

R =(A&0xC3)|Tl |T2; 

break; 
case 0x20: // C <-> D 
15 Tl =(A&0x0C)»2; 

T2 = (A&0x03)«2; 

R =(A&0xF0)|Tl |T2; 

break; 
case 0x30: // A <-> C 
20 Tl =(A&OxC0)»4; 

T2 = (A & OxOC)«4; 

R = (A & 0x33) I Tl I T2 ; 

break; 
case 0x40: // B <-> D 
25 Tl=(A&0x30)»4; 

T2 - (A & Ox03)«4; 

R =(A&OxCC)|Tl |T2; 

break; 
case 0x50: // A <-> D 
30 Tl =(A&OxC0)»6; 

T2 = (A&0x03)«6; 

R = (A & 0x3C) I Tl I T2 ; 

break; 

case 0x60: // A <-> D , B <-> C 
35 Tl =(A&0xC0)»6; 

T2 = (A & Ox03)«6; 

R = (A & Ox3C) I Tl I T2 ; 

Tl =(R&0x30)»2; 

T2 = (R&0x0C)«2; 
40 R =(R&0xC3)|Tl 1T2; 

break; 

case 0x70: // A <-> C , B <-> D 
Tl =(A&0xC0)»4; 
T2 - (A & 0x0C)«4; 
45 R =(A&0x33)|Tl |T2 ; 
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Tl =(R&Ox30)»4; 
T2 = (R & Ox03)«4; 
R =(R&OxCC)|Tl |T2 ; 
break; 

5 }; 

return R; 
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Header file "globaJs.h" used by crypl.h: 

1 5 // Global constants to be used by crypt.h 

char ♦G_CopyRight = 
"CopyRight 1996 All soft Distributing Incorporated\n " 
"All rights reserved. You may not distribute\n 
20 "disassemble, translate, or use this program\n " 
"outside of the contexts of its orriginal purposeAn " 

" af$68()@+91BxZzqQ3PlLdD2@r~n}{><. ?/:;'_'.-P0l- " // signature block 
" Bryan Colvin„Dale Colvin„Bill and Brian„othcrs 

25 // Note: modify program executable using an ofTsct of this string 
// of 2 1 0. You may use whatever you fill like! 

// two reversible maps... i.e. k = MAP [MAP [k]] 
const unsigned char G_MAP0[256]= 

30 { 

0x2A, OxFF, OxlA, 0x15, OxAO. OxCE, 0x89, 0x37, 0x65, OxDl, OxFE. OxB9, OxE7, 
OxB7, 

Ox5F, 0x76, 0x9B. OxBl , OxC8, OxE4, 0x85, 0x03, 0x57, 0x6E, 0xB4, 0xE2, 0x02, 
0x86, 

35 0x6B, 0x99, 0x28. 0xB2, OxEO, 0xF7, 0xD8, OxCl, 0x90, 0x79, 0x62, 0x4B, 0x1 E, 
0x45, 

0x00, 0x7A, 0x7C, 0x7E, OxAC, OxAF, 0xC6, 0xC7, OxDE, OxDC, OxDB, OxD9, 0xD6, 
0x07, 

0xE8, OxFl, 0x46, 0xE9, 0x8B, OxFO, 0x8C, 0x4E, 0x8A, 0xA2, OxBA, 0xD3, OxFC, 
40 0x29, 

Ox3A, 0x48, 0x47, OxA3, OxA5, 0x27, 0xA6, 0xA4, Ox3F, 0x52, 0xF2, OxA7, 0x4F, 
OxEA, 

OxEF, OxBC, Ox8E, 0x16, 0x8D, 0x96, 0x73, 0x72, OxBE, 0x74, OxCO, OxOE, OxF8, 
OxCF, 
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0x26, OxDO, OxF9, 0x08, OxBD, OxF3, OxFA, OxEB, 0xF4, OxlC. OxBF, Ox8F, 0x17, 
0x80, 

0x9D, 0x75, 0x53, 0x5A, Ox5D, 0x71 , OxOF, OxDF, 0x7F, 0x25, 0x2B, OxDD, 0x2C, 
OxDA, 

5 0x2D, 0x78, 0x6F, OxEC, 0xD2, OxF5, OxD5, 0x14. OxlB, 0x95, OxAl, 0x06, 0x40, 
Ox3C, 

Ox3E, 0x58, 0x56, 0x6D, 0x24, OxFD, OxFB, OxE3, OxB5, 0x87, 0x59, OxAA, OxED, 
Ox ID, 

OxEE, 0x10, OxAB, 0x70, 0xC2, 0xE6, 0x04, 0x88, 0x41, 0x49, 0x4D, 0x4A, 0x4C, 
10 0x51, 

0xB3, 0xC3, 0x97, 0x9C, 0x2E, 0xC4, 0xE5, 0x2F, 0xC5, 0x1 1, OxlF, OxA8, 0x18, 
0x94, 

OxF6, OxOD, 0xC9, OxOB, 0x42, OxCA, 0x55, 0x66, Ox5C, 0x6C, 0x5E, 0x23, 0x9E, 
0xA9, 

15 OxAD, OxBO, 0x30, 0x31, 0x12, 0x88, OxBB, 0xD4, 0xD7, OxEl, 0x05, 0x61, 0x63, 
0x09, 

0x82, 0x43, OxCB, 0x84, 0x36, OxCC, 0x22. 0x35, 0x7D, 0x34, 0x33, 0x7B, 0x32, 
0x77, 

0x20, OxCD, 0x19. 0x93, 0x13, OxAE, 0x9F, OxOC, 0x38, 0x3B, 0x53, 0x69, 0x81, 
20 0x98, 

0x9A, 0x54, 0x3D, 0x39, 0x50, 0x67, 0x6A, 0x83, 0xB6, 0x21, 0x60, 0x64, 0x68, 
0x92, 

0x44, 0x91, OxOA, 0x01 

I; 



const unsigned char G_MAP1 [256]== 
{ 

OxFE, OxFC, 0xF9, OxF8, 0xF6, OxF3, OxFl, OxEE. OxED, OxEA, OxE9, 0xE6, OxE5, 
30 0xE2, 

OxEl . OxDE, OxDD, OxEO, OxE3, 0xE7, OxEB, OxEF, 0xF2, 0xF5, 0xF4, OxFO, OxBF, 
0xC2, 

0xD9, 0xD8, 0xD6, OxD5, OxD3, 0xD2, OxDO, OxCF, OxCD, OxCC, OxCA. OxCB, 
OxCE, OxDl, 

35 0xD4, 0xD7. OxDB, OxDA, OxB8, OxB6. 0x80, 0x82, 0x83, 0x85, 0x86, 0x88, 0x89, 
Ox8B, 

Ox8A, OxAl, 0x9E, 0x9B, 0x98, 0x95, 0x93, 0x90, Ox8D, 0x8E, 0x91, 0x92. 0xA9, 
OxA8, 

0xA6, OxA5, OxA3, 0xA2, OxA4, 0xA7, OxAC, OxAB, OxBO, OxAF, 0xB4, OxB3, OxB7, 
40 0xB5, 

OxBl , OxAE, 0xC5, OxCl , OxCO, OxDC. OxDF, 0xE4, OxEC. 0xE8, OxFF, OxFD, OxFB, 
OxFA, 

OxF7, 0xC9, 0xC7, OxC4, OxC3. 0xC6, 0xC8. 0xB2. OxBB, 0xB9, OxBA, OxBD OxBC 
OxBE, 



38 



05/28/2004, EAST Version: 1.4.1 



47 



6,041,123 



48 



OxAA, 0x9F, 0x9D, 0x9A, 0x97. 0x96, 0x94, 0x99, 0x9C, OxAO, 0x7C, 0x81, Ox7A, 
0x84, 

0x87, 0x8C, 0x30, 0x7B, 0x31, 0x32, 0x7D, 0x33, 0x34, Ox7E, 0x35, 0x36, 0x38, 0x37, 
0x7F, 0x40, 0x41, OxAD, Ox3F, 0x42, 0x43, 0x3E, 0x76, 0x3D, 0x75, 0x74, Ox3C, 
5 0x77, 

6x73, Ox3B, 0x78, 0x72, 0x3 A, 0x71, 0x79, 0x39, 0x49, 0x48, 0x4A, 0x47, 0x46, 
0x4B, 

0x45, 0x44, 0x70, 0x4D, 0x4C, 0x8F, 0x55, 0x4F, 0x4E, 0x54, 0x69, 0x51, 0x50, 0x53, 
0x2F, 0x52, 0x2E, 0x6B, 0x6C, 0x6A. 0x6E, 0x6D, 0x6F, 0x1 A, 0x58, 0x57, Ox IB, 
10 0x66, 

0x65, 0x56, 0x67, 0x64, 0x68, 0x63, 0x26, 0x27, 0x25, 0x24, 0x28, 0x23, 0x22, 0x29, 
0x21, 0x20, Ox2A, OxlF, OxlE, 0x2B, OxID, OxlC, 0x2D, Ox2C, 0x59, 0x10, OxOF, 
0x5 A, 

0x1 1. OxOE. OxOD, 0x12, Ox5B, OxOC, OxOB, 0x13, Ox5D, OxOA, 0x09, 0x14, 0x5C, 
15 0x08, 

0x07, 0x15, 0x19, 0x06, 0x16, 0x05, 0x18, 0x17, 0x04, 0x62, 0x03, 0x02, 0x61, 0x60, 
0x01, Ox5F, 0x00, 0x5E 
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I claim: 

1. A communications system, comprising: 

a transmitting client and a receiving client, each client 
having an associated secure key and an encryptor/ 
decryptor for encrypting and decrypting messages 
using the secure key; and 

a master key router remotely disposed from the transmit- 
ting client and the receiving client having a decryptor 
for decrypting messages encrypted with the secure key 
of the transmitting client, and having au encryptor for 
encrypting messages with the secure key of the receiv- 
ing client; 

wherein messages between the transmitting client and the 
receiving client pass through the master key router, and 
wherein the master key router is configured to decrypt 
the message using the secure key of the sending chent 
and a unique algorithm associated with the sending 
client and encrypt the message using the secure key of 
the receiving client and a unique algorithm associated 
with the receiving client. 

2. The communications system of claim 1, wherein each 
client has an associated index key. 

3. The communications system of claim 2, further com- 
prising: 

a master key server, the master key server having a 
database storing duplicates of the secure keys associ- 
ated with each of the clients indexed according to the 
clients* respective index keys; 

wherein the master key router communicates the index 
keys associated with the sending client and the receiv- 
ing client to the master key server, the master key 
server uses the index keys associated with the sending 
client and the receiving client to look up the secure keys 
for the sending client and the receiving client respec- 
tively and communicates those secure keys to the 
master key router. 

4. The communications system of claim 3, wherein the 
master key server is configured to add new clients. 

5. The communications system of claim 1, wherein the 
master key router is configured to use secure keys of 
arbitrary length, 

6. The communications system of claim 4, wherein the 
algorithms arc determined by patching blocks of data to an 
algorithm template. 

7. The communications system of claim 6, wherein the 
blocks of data patched to the algorithm engine contain the 
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initial conditions for a random number generator within the 
algorithm engine. 

8. The communications system of claim 7, wherein the 
blocks of data patched to the algorithm engine further 

5 contain the initialization of pointers to cause each data 
element in the streams of data to be encrypted to be 
scrambled using a different method. 

9. The communications system of claim 4, wherein the 
unique algorithms for each client are generated by means of 
a pseudo-random number generator that uses clients' index 
keys as seeds such that the master key server may derive 
clients' algorithm numbers without the requirement of stor- 
ing said algorithm number in the database within the master 

^5 key server. 

10. The communications system of claim 4, wherein the 
master key router*s decryptor decrypts messages encrypted 
with a secure key of a first client utilizing the inverse of said 
first client's encryption algorithm and the master key rout- 

20 er*s encryptor encrypts messages with a secure key of a 
second client utilizing the inverse of said second client's 
encryption algorithm. 

11. The communications system of claim 10, wherein the 
encryption algorithms of said first client and said second 

25 client differ and are determined by patching blocks of data 
to an algorithm engine and wherein the master key router is 
configured to derive a any particular client's algorithm by 
patching the algorithm engine with the same blocks of data 
used to determine that client's algorithm. 

12. The communications systems of claim 1, wherein 
each secure key used for sending a message is modified after 
the message is transmitted, 

13. The communications system of claim 1, wherein the 
2j encryption and decryption of communications between the 

transmitting client and the receiving client utilizes state 
variables to create a random number stream and the state 
variable data is only partially used for each character of data 
to be transmitted or received. 

40 14. The communications system of claim 1, wherein the 
communications between the transmitting client and the 
receiving client comprises a stream of characters and 
encryption and decryption of the stream of characters 
involves modifying each character in the stream of charac- 

45 ters by a different method of encryption or decryption. 
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